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Let's get recursive. This 
month Wilf Hey takes a 
look at some rather 

introspective programs. 


y wife Barbie once 
accompanied me on a 
business trip. My manager 


planned to meet me on the last day, as he 
would be signing for our hotel bill. Two 
days before the end of the trip, he called 
to say he was ill, and would not be 
leaving base. He confirmed this with the 
hotel — which was as well, because I 
hadn’t the means to pay the hotel bill. 

Nevertheless, Barbie is a congenital 
worrier. As I was checking out, she 
waited nervously in the lobby. Feeling a 
little more cruel than usual, I walked to 
her and said softly in her ear, ‘No 
trouble dear, but the manager would like 
me to accompany him to the police 
station to explain the situation’. She took 
one step forward, turned and spoke 
aloud, ‘Sir — I don’t know you!’ (She 
later explained that this was simply a 
ploy to stay out of jail herself, so she 
could raise bail.) 

I think each of us has, on some 
occasion, been guilty of denying the 
power of the PC simply because we 
lacked the stamina to test its limits. One 
regular SuperDisk contributor, John 
Worley, tells us that most of his 
programs arise out of things that experts 
tell him ‘can’t be done’. As he puts it, 
his success in programming can be 
traced to his ignorance of the limitations 
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he should have known from the start. 
Perhaps a good New Year’s 
resolution for the programmer is to bite 
his tongue the next time he finds himself 
wanting to say, *... but you can’t do that’. 


HAVE A RECURSIVE CHRISTMAS 
The little QuickBASIC program 
presented on the next page will print the 
Twelve Days of Christmas carol on your 
PC screen: note that the numbers on the 
left side were inserted just so we could 
identify the lines here — they are not 
actually required at alli. 

This program features a technique 
called recursion, an advanced 
programming method involving a 
definition, algorithm or subroutine 
making self-reference — calling on itself 
from within itself. Although quite useful 
it is not easy to think of a problem 
readily tackled by this method. 

In this case, the subroutine called 
Gifts is recursive, because of the self- 
reference in line 5100. This would 
appear an impossible situation — self- 
reference making everything circular. An 
endless loop must be in the offing. 

Not really; there is a route through 
Gifts that does not make this self- 
reference: can you find it? Look at lines 
4700 to 4900: the CASE ELSE condition 
simply prints a blank line, and then exits 


the subroutine — before reaching line 
5100, and therefore not referencing 
itself. This condition — the CASE ELSE 
— happens when the parameter x passed 
to Gifts is not in the range | to 12. We 
could make this happen if we entered 
Gifts with a value of 13, but this in fact 
doesn’t happen here: in the main 
program (just lines 300 to 900) we call 
Gifts with the parameter Verse — which 
can only have a value between one and 
twelve: see line 300. 

How do we hit the ELSE case, thus 
avoiding a fatal, endless loop? Let’s take 
a closer look at the self-reference in line 
5100: note that if we entered Gifts (from 
line 0700, say) with a parameter value of 
seven, then line 5100 will call Gifts with 
a new value of six. Naturally, this new 
incarnation of Gifts will give itself 
(similarly) a value of five, and so on... 

..Until eventually Gifts will be 
‘tricked’ into calling itself with the value 
zero (right after it has printed the CASE 
| line, ‘a partridge in a pear tree’). When 
the next incarnation of Gifts sees a value 
zero, guess what? A CASE ELSE 
condition appears, and Gifts terminates 
without calling itself. At this point, it 
may be hard to imagine, but control is 
passed back to the previous incarnation 
of Gifts, which (having called itself 
already) has nothing more to do, and 
(having arrived at line 5200) ends itself, 
passing control to its predecessor in turn. 
Eventually the version of Gifts that had 
been called by the main program will 
pass back control, and we find ourselves 
at line 0800. 

This feature — having at least one 
case where the self-reference is avoided 
— is essential to prevent an eternal loop: 
it is usually given the rather inglorious 
name, bottoming out. 

Study this program, and you should 
be able to see that recursion is indeed a 
most powerful tool for solving this 
particular problem. Just one little note: 
the WHILE loop in line 0800 is there 
only so that there is a pause between 
verses: the operator must hit a key to 
continue with the next verse, starting 
again at the top of the page. 

Not all languages support recursion 
with its functions and subroutines, so as 
you experiment, beware. 

Now | issue a challenge. Not all 
recursion problems involve countdowns 
such as this carol does. Here is an 
example of quite a different situation: 
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one in which we do not know when — or 
if — there is a bottoming out for any 
particular starting number. I invite 
readers to submit — in their favourite 
language — a recursive routine that will 
perform the function I now describe: it is 
thought that for every positive whole 
number, this function will eventually 
bottom out, but nobody knows for sure! 

The challenge: write a function, 
using recursion, that will take a whole 
number as a parameter. If the number is 
even, it should be halved, and the new 
value used for the next level of 
recursion. If the whole number is odd, 
the value should be tripled, and then one 
added, and this new value used for the 
next level of recursion. The function 
bottoms out when its value is one. 

To see this working, print the input 
value each time. For example, running 
this function from a little program that 
passes inward a value of three, we 
should expect to see the printout: 

3105168421 

The most interesting submission will 
be published here, amid much praise. 


SMALL MINDS 

‘A foolish inconsistency,’ said Ralph 
Waldo Emerson, ‘is the hobgoblin of 
small minds’. According to him, if you 
feel the need to be absolutely precise, 
you may be falling into an intellectual 
trap. Recursively speaking, I’m thinking 
of a fatal endless loop: but this is not 
precisely so. You see, recursion 
normally works in the programming 
environment by nested calls: each new 
iteration in the recursion is a new level 
of nesting. Recursion works in so many 
computer languages because they 
implement calls by putting return points 
and parameters into a LIFO (or 
‘pushdown/popup’ ) stack, these stacks 
will be limited in length: at most, they 
can occupy the rest of the memory 
(beyond your program) before they 
either (i) clog up; (ii) destroy something 
necessary for running the program; (iii) 
lose their way; or (iv) all of the above. 
Even quite a small stack could handle 
many levels of nesting, but there’Il be a 
limit. The theory behind recursion still 
leads perilously close to endless loops. 


HORSES FOR COURSES 

AC Bradley wrote to Help Screen with 
a suggested skeleton .BAT file that 
would insist on backup procedures after 
running crucial programs. Simple and 
useful as this is, it highlighted for me 
some of those DOS utilities that are 
notable for not existing! 

In this particular case, directions to 
insert backup diskettes are put on the 
screen with ECHO, and then a PAUSE is 
issued. Too bad there isn’t a DOS 
command to test whether the diskette 
that was inserted is correct. But there is: 
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I suddenly remember the IF EXISTS 
directive; I can arrange a tiny identifying 
file to be recorded on the proper diskette 
(like BACKUP.JAN) and then simply 
test for its existence. 

This is not really sufficient. What I 
need is not just something to test 
whether the diskette is the correct one; I 
need to know whether there is a diskette, 
and whether I am able to write on that 
diskette. In the WORKSHOP section of 
the SuperDisk this month you will find 
DRIVE.COM, a little program that can 
provide you with those two pieces of 
information without suffering those 
horrible ‘Retry, Abort, Ignore’ messages 
if you key past the PAUSE too early. 

Many very useful SHORTIES take 
this form — a command of the type 
that the creators of DOS really should 
have provided. 


I suggest recording such needs — this can 
make life much easier for DOS users. 
Even if you cannot think of a way to 
provide such a program, send in your 
needs and ideas, along with how you 
would like to use them. SHORTIES are 
usually best coded in a low-level 
language, or in machine code itself. If 
you are confined to BASIC, never mind 
— there are plenty of others willing to 
‘have a go’ with a good idea, so please 
share it with us. @ 


Write with questions, suggestions or 
comments to: 


Wilf’s Programmers’ Workshop 
PC PLUS 

30 Monmouth Street 

BATH, Avon 

BA1 2BW 


